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(57) Abstract: The present invention relates to a system and a method for charging in a communication network and tc 
cation network charging server. The system comprises a client (1) associated with the network for providing services to subscribers 
associated with the network. The charging server (2) is adapted to handle subscriber account information, and the said client (1) 
is adapted to send a first charging request message for a service, to the charging server (2) before the service is provided, using an 
on-line charging protocol (3) .The charging server (2) is also adapted to perform pre- reservation of an amount of resources from the 
subscriber's account, wherein the amount depends on a requested amount included in the message about the service, and to return 
an answer message including information indicating whether an amount of resources is pre -reserved from said subscriber account 
for enabling usage of the service to the client ( I ) using the on-line charging protocol (3). 
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SYSTEM AND METHOD FOR CHARGING IN A COMMUNICATIONS NETWORK 
AND A COMMUNICATIONS NETWORK CHARGING SERVER 

Technical field of the invention 

5 The present invention relates in general to 

communication networks and more specifically to a system 
and a method for charging in a communication network and 
to a communication network charging server. 

10 Background of the invention 

In the present communication networks i.e. 
telecommunications networks and data communications 
networks there are no real-time charging protocol 
mechanisms over which a client providing services to the 

15 subscriber would be able to debit subscriber's account 
residing in a charging server based on the charges 
calculated by the client. 

The current real-time charging protocol mechanisms 
do not allow any client to request charging server to rate 

20 a service event (s) and return the number of the events 
that are allowed be provided to the subscriber. 

Furthermore, the current real-time charging protocol 
mechanisms do not allow any client to inform the sub- 
scriber before and after Service Event execution about the 

2 5 monetary amount to be used. 

The new network generation specifies (e.g. 3G 
Charging and Billing requirements) the more critical 
requirements for the Accounting applications (Charging 
systems) of the communication networks. The Accounting 

30 application must be able to rate Accounting information in 
real-time. For example, the service environment processes 
service event information, which has to be rated before or 
at service delivery/execution . 

There exist also requirements for the End User 

35 credit control of the new communication networks 

generation. The Accounting application must be able to 
check the End User's account for coverage for the 
requested Service Event charges prior to execution of that 
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Service Event. All the chargeable events related to a 
specific account must be barred to the End User when the 
credit of that account is exhausted or expired. 

In the next generation networks the number of 
5 services offered to the End User and the number of actors 
delivering these services to End Users will grow. To 
fulfil all these new requirements new types of mechanisms 
for charging in a data communication network are needed, 
which will support the communication between Credit 

10 Control applications/servers and the service environment. 
A particular problem arises in connection with 
intelligent network (IN) services, such as Premium Rate 
calls, Mobile Virtual Private Network (VPN) , Prepaid 
charging and Personal Number. Since prepaid usually is an 

15 IN service itself it is not convenient to provide prepaid 
of other IN services for subscribers . To provide prepaid 
of other IN services, the prepaid functionality has been 
integrated with the particular other IN service in prior 
art communications system. Hence, each IN service has to 

2 0 be redesigned with prepaid functionality added to be able 

to offer the service as prepaid. 

Summary of the present invention 

It is an object of the present invention to overcome 
25 or at least mitigate the disadvantages of the prior art. 
The present invention provides a system and a method for 
charging in a communication network and a communication 
network charging server. 

According to a first aspect of the present invention 

3 0 there is provided a system for charging in a communica- 

tions network, comprising a client associated with the 
network for providing services to subscribers associated 
with the network, wherein the system comprises a charging 
server adapted to handle subscriber account information, 
3 5 the client is adapted to send a first charging request 

message for a service, to the charging server before the 
service is provided, using an on-line charging protocol, 
the charging server is adapted to perform pre-reservation 
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of an amount of resources from the subscriber's account 
defined by information included in said message about said 
service, and to return an answer message including 
information indicating whether enough resources are pre- 
5 reserved from said subscriber account for enabling usage 
of said service to the client using the on-line charging 
protocol . 

According to a second aspect of the present 
invention there is provided a system for charging in a 

10 communications network, comprising a client associated 
with the network for providing services to subscribers 
associated with the network, wherein the system comprises 
a charging server adapted to handle subscriber account 
information, the client is adapted to send- a first 

15 charging request message for a service, to the charging 
server before the service is provided, using an on-line 
charging protocol, and the charging server is adapted to 
rate the service and return an answer message to the 
client using an on-line charging protocol, wherein the 

2 0 answer message includes the price indications of the 
requested service event (s). 

According to a third aspect of the present invention 
there is provided a method for charging in a 
communications network, comprising a client associated 

2 5 with the network for providing services to subscribers 

associated with the network and a charging server adapted 
to handle subscriber account information having the 
subscriber account information, wherein the client (1,14) 
sends a first charging request message for a service, to 
30 the charging server before the service is provided, using 
an on-line charging protocol, the charging server performs 
pre-reservation of an amount of resources from the 
subscriber's account defined by information included in 
the message about the service, and returns an answer 

3 5 message including information indicating whether enough 

resources are pre-reserved from said subscriber account 
for enabling usage of the service to the client using the 
on-line charging protocol. 
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According to a fourth aspect of the present 
invention there is provided a method for charging in a 
communications network comprising a client associated with 
the network for providing services to subscribers 
5 associated with the network and a charging server adapted 
to handle subscriber account information having the 
subscriber account information, wherein the client sends 
a first charging request message for a service, to the 
charging server before the service is provided, using an 
10 on-line charging protocol, the charging server rates the 
service and returns an answer message to the client using 
an on-line charging protocol, wherein the answer message 
includes the price indications of the requested service 
event ( s ) . 

15 According to a fifth aspect of the present invention 

there is provided charging server for charging service 
usage in a communications network, wherein the charging 
server is adapted to handle subscriber account 
information, receive a first charging request message for 

20 a service from a client, before the service is provided, 
using an on-line charging protocol, perform pre- 
reservation of an amount of resources from the 
subscriber's account defined by information included in 
the message about the service, and to return an answer 

25 message including information indicating whether enough 
resources are pre-reserved from said subscriber account 
for enabling usage of said service to the client using the 
on-line charging protocol. 

According to a sixth aspect of the present invention 

30 there is provided a charging server for charging service 
usage in a communications network, wherein the charging 
server is adapted to handle subscriber account 
information, receive a first charging request message for 
a service from a client, before the service is provided, 

35 using an on-line charging protocol, and rate the service 
and return an answer message to the client using an on- 
line charging protocol, wherein the answer message 
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includes the price indications of the requested service 
event (s) . 

Advantages of the present invention are that any 
client network can debit end subscribers 1 account 
5 specified in the charging server, any client can use the 
charging server to rate service event (s) without knowledge 
about the actual price and the control how many such 
service events can be provided to the user, and the client 
can provide cost estimation to subscribers before service 

10 execution and a final cost for the service usage after the 
service execution. Still another advantage is that 
intelligent network (IN) services can be provided with 
prepaid rating without redesign of the complete IN 
service. Hence, each IN service does not need to be 

15 redesigned with prepaid functionality added to be able to 
offer the service as prepaid. 

Brief description of the drawings 

For a better understanding of the present invention 
2 0 and in order to show how the same may be carried into 
effect reference will now be made to the accompanying 
drawings, in which: 

Figure 1 illustrates the system for charging in a 
communication network according to the present invention, 

2 5 Figure 2 illustrates the message sequence for 

account debiting by monetary units in the system for 
charging in a communication network according to the 
present invention, 

Figure 3 illustrates the message sequence for rating 

3 0 service. events in the system for charging in a 

communication network according to the present invention, 
Figure 4 illustrates the message sequence for cost 
estimation for charging in a communication network 
according to the present invention, 
35 Figure 5 illustrates a block diagram of the system 

for charging in a communication network according to the 
present invention, 
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Figure 6 illustrates another embodiment of the 
system in figure 1, and 

Figure 7 illustrates the message sequence for 
account debiting in the system for charging in a 
5 communication network in figure 6. 

Detailed description of the invention 

The solution according to the present invention 
presents a new mechanism for charging in a communication 
network. This new charging mechanism allows any client 
10 network to debit end subscriber's account specified in a 
new On-line Charging Server. The monetary amount to be 
debited is determined by the client. 

In the new charging mechanism according to the 
present invention a client in the network can use the 
15 Charging Server to rate service event or service events 

without knowing the actual price and control how many such 
a service events can be provided to subscriber. In the new 
charging mechanism according to the present invention the 
client can further provide to subscriber cost estimation 
2 0 before service execution and final cost after service 
execution. 

Figure 1 illustrates the system for charging in a 
communication network according to the present invention. 
In the charging system according to the present invention 

2 5 there is a client 1 providing services to the subscriber 

and a charging server or charging control server 2 having 
the subscriber account information. The client 1 and the 
charging server 2 communicate using an On-line Charging 
Protocol 3. The On-line Charging Protocol 3 is a bi- 

3 0 directional protocol that supports real-time charging. 

Real-time charging is charging which is performed as a 
part of rendering services. Preferably, the On-line 
Charging Protocol 3 is based on an IP protocol such as the 
Diameter protocol. Alternatively, the On-line Charging 
35 Protocol is based on Parlay protocol, INAP CS1 protocol or 
SS7 . 

Figure 2 illustrates the message sequence for 
account debiting by monetary units in the system for 
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charging in a communication network according to the 
present invention. The client may reserve money for a 
subscriber to use for services charging wise controlled by 
the client 1 by sending a Charging-Request 4 message to 
5 the charging server 2. An alternative Charging-Request 
message is marked with a reference number 6. 

In the Charging-Request 4, 6 the subscriber to be 
charged for is identified by a specific Subscriber ID, for 
instance IMSI, MSISDN, IP address or SIPJJRL. The client 1 

10 indicates how much money it wants to reserve for the use 
of services controlled by it (Reserved Monetary Amount) . 
The client 1 can also indicate to the charging server 2 
what is the expected duration during which the monetary 
amount is to be consumed (Reservation Duration) . The 

15 charging server 2 uses the message parameters of Charging- 
Request 4, 6 to determine how it should response to the 
request 4, 6. 

The charging server 2 then determines, even 
independent on the value requested by the client 1, the 

20 monetary amount to be reserved from subscriber's account. 
The amount can be for instance a default value independent 
from the requested value. For instance, the amount can be 
equal to the requested value in case there is enough money 
on the account. Likewise, the amount can be less than what 

2 5 is requested in case there is not enough money on the 

subscriber's account, or in case the subscriber is 
unreliable . 

It can also be that the client 1 does not indicate a 
requested monetary amount in the Charging-Request 4, 6. In 

3 0 this case the charging server 2 needs to determine the 

monetary amount to be reserved based on other message 
parameters, such as the service used e.g. Service Event 
Information, such as time, data volume, service specific 
events (e.g. web-pages downloads, timetable inquires, etc) 
3 5 and money, of the Charging-Request 4, 6 or based on 

configuration parameters in the charging server 2. The 
charging server 2 returns the reserved monetary amount in 
a Charging -Answer 5 message to the client 1. An 
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alternative Charging-Answer message is marked with a 
reference number 7 . 

The charging server 2 also determines the allowed 
duration to be used for the consuming of the reserved 
5 monetary amount. The duration can be a default value 
independent on the requested value. For instance, the 
duration can be bigger than the requested value in case of 
signalling capacity problems, or duration can be less than 
what is requested in case the subscriber is unreliable. 

10 In case the client 1 does not indicate a requested 

Reservation Duration, then the charging server 2 needs to 
determine the duration to be reserved based on other 
message parameters of Charging -Request 4, 6 or based on 
configuration parameters in the charging server 2. The 

15 charging server 2 returns the reservation duration in a 
Charging-Answer 5, 7 message to the client 1. 

The charging server 2 can also choose not to put any 
time limit on the usage of the monetary amount, in which 
case it does not send message parameter Reservation 

2 0 Duration. The charging server 2 can also indicate in the 

Charging-Answer 5, 7 message to the client 1 that the 
reservation was unsuccessful e.g. in case the subscriber's 
account is totally empty. 

When the Charging-Answer 5, 7 indicates that a 
25 monetary amount is successfully reserved, then the client 
1 allows the subscriber to initiate chargeable 
transactions in the client network. Upon the entire 
monetary amount reserved by the charging server 2 has been 
spent by the subscriber, the client 1 re-requests for more 

3 0 money from the charging server 2 by sending a new 

Charging-Request 6. 

In case the monetary amount reserved by the charging 
server 2 is not spent upon the expiration of the 
reservation time allocated by the charging server 2, the 
35 client 1 contacts the charging server 2 with a new 

Charging-Request 6 indicating how much money was actually 
used by the subscriber (Used Monetary Amount) . The new 
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Charging-Request 6 message can also include a request for 
more money. 

As the charging server 2 receives the knowledge on 
the money used by the subscriber, it returns the initially 
5 reserved monetary amount back to the account, and deducts 
the used monetary amount from the account. Thereafter, the 
charging server 2 starts reserving the next monetary 
amount from the account. If the knowledge on the money 
used by the subscriber is not received in the message, the 

10 charging server 2 deducts the account based on the 

reserved amount at the reception of previous Charging- 
Request 4 , 6 . 

In case the initial reservation request 4 is 
unsuccessful, the client 1 will determine whether it wants 

15 to retry the reservation e.g. with smaller value for 

Reserved Monetary Units. The charging server 2 can give 
some input to the client 1 to determine what to do in the 
unsuccessful reservation case. The charging session 
between the client and the Charging Server can be finished 

2 0 by the client 1 according to the instructions from the 

charging server 2 (Close Charging Session) . 

The charging server 2 includes to each Charging - 
Answer 5, 7 the accumulated cost (Accumulated Cost) for 
charging session. The final answer message 5, 7 also 
25 includes the total cost of the charging session. 

Figure 3 illustrates the message sequence for rating 
service events in the system for charging in a 
communication network according to the present invention. 
The client 1 may request rates for service events and 

3 0 reserve money for a subscriber to use the service by 

sending a first Charging-Request 8 message to the charging 
server 2 . An second Charging-Request message is marked 
with a reference number 10. 

In the Charging-Request 8, 10 the subscriber to be 
35 charged for is identified by a specific Subscriber ID, for 
instance IMSI, MSISDN or SIP_URL. The client 1 indicates 
the service event type (Service event Information) and 
number (Number of Events) of such events, which it wants 
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to be rated. The client 1 can also indicate to the 
charging server 2 what is the expected duration during 
which the service events are to be consumed (Reservation 
Duration) . The charging server 2 uses the message 
5 parameters of Charging -Request 8, 10 to determine how it 
should response to the request 8, 10. 

The charging server 2 then rates the requested 
service using service event information and number of 
requested information, and reserves corresponding amount 

10 of money from the subscriber account. 

The charging server 2 then determines, even 
independent on the requested number of events by the 
client 1, the number of events, which are granted to be 
used by the subscriber. The number of events can be for 

15 instance a default value independent from the requested 
value. For instance, the number of events can be equal to 
the requested value for instance in case there is enough 
money on the account. Likewise, the number of events can 
be less than what is requested in case there is not enough 

2 0 money on the subscriber's account, or in case the 
subscriber is unreliable. 

The charging server 2 returns the number of events, 
which are granted to be used by the subscriber in a 
Charging -Answer 9 message to the client 1. An alternative 

25 Charging -Answer message is marked with a reference number 
11 . 

The charging server 2 also determines the allowed 
duration to be used for the consuming of the reserved 
monetary amount. The duration can be a default value 

30 independent on the requested value. For instance, the 

duration can be bigger than the requested value in case of 
signalling capacity problems, or duration can be less than 
what is requested in case the subscriber is unreliable. 

In case the client 1 does not indicate a requested 

35 Reservation Duration, then the charging server 2 needs to 
determine the duration to be reserved based on other 
message parameters e.g. Service Event Information of 
Charging-Request 8, 10 or based on configuration 
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parameters in the charging server 2. The charging server 2 
returns the reservation duration in a Charging-Answer 9, 
11 message to the client 1. 

Alternatively, the Charging Server does not put any 
5 duration limit on the usage of the granted number events, 
in which case it does not send message parameter 
Reservation Duration. 

The charging server 2 can also choose not to put any 
limit on the usage of the granted number events, in which 

10 case it does not send message parameter Reservation 

Duration. The charging server 2 can also indicate in the 
Charging-Answer 9, 11 message to the client 1 that the 
reservation was unsuccessful e.g. in case the subscriber's 
account is totally empty. 

15 When the Charging-Answer 9, 11 indicates that rating 

of the service event and reservation of a monetary amount 
is successful, then the client 1 allows the subscriber to 
initiate chargeable transactions in the client network. 
Upon the all granted events reserved by the charging 

2 0 server 2 have been spent by the subscriber, the client 1 

re -requests for more service events from the charging 
server 2 by sending a new Charging-Request 8, 10. 

In case the granted number of events reserved by the 
charging server 2 is not spent upon the expiration of the 
25 reservation time allocated by the charging server 2, the 
client 1 contacts the charging server 2 with a new 
Charging-Request 10 indicating how many events was 
actually used by the subscriber (Number of Used Service 
Events) . The new Charging-Request 10 message can also 

3 0 include a request for more events. 

As the charging server 2 receives the knowledge on 
the service events used by the subscriber, it returns the 
initially reserved monetary amount back to the account, 
i.e cancels the reservation, and deducts a monetary amount 
3 5 equal to the number of used service events from the 

account. Thereafter, the charging server 2 rates the new 
service event request and starts reserving the 
corresponding amount from the account. If the knowledge on 
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the service events used by the subscriber is not received 
in the message, the charging server 2 deducts the account 
based on the already reserved amount. 

In case the initial reservation request 8, is 
5 unsuccessful, the client 1 will determine whether it wants 
to retry the reservation e.g. with less number of events. 
The charging server 2 can give some input to the client 1 
to determine what to do in the unsuccessful reservation 
case. The charging session between the client and the 
10 Charging Server can be finished by the client 1 according 
to the instructions from the charging server 2 (Close 
Charging Session) . 

The charging server 2 includes to each Charging- 
Answer 9, 11 the accumulated cost (Accumulated Cost) for 
15 charging session. The final answer message 9, 11 also 
includes the total cost of the charging session. 

Figure 4 illustrates the message sequence for cost 
estimation for charging in a communication network 
according to the present invention. The client 1 may 

2 0 inquire the price of the service event (Pricing Enquiry 

Indication) before service execution by sending a 
Charging-Request 12 message to the charging server 2 . 

By using service event information and number of 
requested information, the charging server 2 calculates 
25 the price of the requested service. The charging server 2 
does not perform any account balance check nor account 
adjustment. The charging server 2 returns the calculated 
price indication in a Charging-Answer 13 message to the 
client 1. The client 1 can then advice subscriber the cost 

3 0 of the requested service. 

Figure 5 illustrates a block diagram of the system 
for charging in a communication network according to the 
present invention. In the charging system according to the 
present invention there is a Service/Network Element 14 
3 5 and Service Consumers 15, 16. Service/Network Element 14 
can be a Service Element 14 that provides Services to 
Service Consumers 15, 16 or a Network Element 14 that 
enables Service Consumers 15, 16 access to network usage. 
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In the charging system according to the present 
invention there is also a Credit Control Server 17. Before 
the service is provided, the Service/Network Element 14 
contacts the Credit Control Server 17 using Credit Control 
5 Protocol 18 with Service Event information included (as 

described in the previous Figures 1-4) . The Credit Control 
Server 17, depending on and defined by the Service Event 
information, performs the rating of the Service Event, 
pricing of the Service Event, credit check and pre- 
10 reservation. 

In the charging system according to the present 
invention there is also an Accounting Server 19. The 
Accounting Server 19 is a server handling the accounting 
of the different events and services in the customer's 
15 network. 

The Service/Network Element 14 can alternatively 
deliver the Service Event Information to the Accounting 
Server 19 using Accounting Protocol 20, which Accounting 
Server 19 may contact the Credit Control Server 17. The 
2 0 Credit Control Server 17 and the Accounting Server 19 are 
logical entities. An implemented configuration can contain 
both the Credit Control Server 17 and the Accounting 
Server 19 forming a single host or charging server. 

When the Service Consumer 15, 16 requests a service 

2 5 the request is forwarded to a Service/Network Element 14 

in home domain, that is the same administrative domain, in 
which the Service Consumer's 15, 16 Credit Control Server 
17 is located. 

Next the Service/Network Element 14 authorizes the 

3 0 Service Consumer 15, 16 and sends a request to the Credit 

Control Server 17 . The Service/Network Element 14 can get 
the authorization information from an authorization 
server. The authorization server may also send the 
Service/Network Element 14 instructions and identification 
3 5 data regarding the Credit Control Protocol 18 and the 
Accounting Protocol 20. 
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The system for charging in a communication network 
according to the present invention has two main service 
scenarios : 

a one time event that is used for price enquiry 
5 and credit control, and 

several interrogations that are used for session 
based credit control . 

The one time event is used when the Service/Network 
Element 14 wants to know the cost of the Service Event 
10 without any credit-reservation. It can be used also for a 
credit control when one time event has occurred in service 
environment. There might exist services offered by 
Application Service providers, whose prices are not known 
in the Service/Network Element. End User might also want 
15 to know the exact price of a Service Event before 
requesting the Service Event. 

After a request 12 from the client the Credit 
Control Server 17 calculates the cost of the requested 
Service Event, but it does not perform any account balance 
20 check or credit-reservation from the account. The price of 
the requested Service Event is returned to the 
Service/Network Element 14 with the answer message 13 . 

There are certain one time events for which service 
execution is always successful in the service environment. 

2 5 In these cases Service/Network Element 14 can use the one 

time event scenario for real Credit Control. The 
Service/Network Element 14 sends a credit control request 
message 4, 8 to the Credit Control Server 17 before the 
Service/Network Element 14 allows the Service Event to the 

3 0 Service Consumer 15, 16. 

The Credit Control Server 17 rates the Service Event 
and deduct the corresponding monetary amount from Service 
Consumer's 15, 16 account, and returns a credit control 
answer message 5, 9 to the Service/Network Element 14. 
35 In a session based Credit Control there are several 

interrogations: the first, intermediate and the final 
interrogation. The Service/Network Element 14 sends a 
first interrogation message 4, 8 to the Credit Control 
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Server 17 before the Service/Network Element 14 allows the 
Service Event to the Service Consumer 15, 16. 

The Credit Control Server 17 rates the Service Event 
and deduct the corresponding monetary amount from Service 
5 Consumer's 15, 16 account, and returns a credit control 

answer message 5, 9 to the Service/Network Element 14. The 
type of the granted service units can be time, volume, 
event or money depending on the type of Service Event. 
The Intermediate Interrogation can be sent as 

10 follows. When all the granted service units are spent by 
the Service Consumer 15, 16, the Service/Network Element 
14 sends a new request 6, 10 to the Credit Control Server 
17. The Credit Control Server 17 rates the Service Event 
and deduct the corresponding monetary amount from Service 

15 Consumer's 15, 16 account, and returns a credit control 

answer message 7, 11 to the Service/Network Element 14 as 
in the first interrogation. There can be several 
intermediate interrogations within one session. 

When the Service Consumer 15, 16 finishes the 

2 0 Service Event or when all the granted units are used, the 
Service/Network Element 14 sends a Final Interrogation 6, 
10 message to the Credit Control Server 17. After final 
interrogation the Credit Control Server 17 refunds the 
reserved credit amount not used to the Service Consumer's 

2 5 15, 16 account, deducts the used monetary amount from the 

account and returns an answer message 7, 11. 

The solution according to the present invention 
proposes a new protocol mechanism by which a client is 
able to charge certain amount of monetary units for 
30 particular event (s) occurring in the 

(com/service/multimedia) network under the control of the 
charging server. Monetary amount to be charged is 
determined by the client that sends a charging request to 
a server holding an account database. The server reserves 

3 5 the money from the account and allocates a duration during 

which the money is to be consumed or the server to be 
recontacted. Return message is sent back to the client. 
Upon subscriber having spent the reserved money, the 
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client requests the server to withdraw the monetary amount 
from the account. 

In the new protocol mechanism solution according to 
the present invention a client is able to request the 
5 Charging Server (server holding an account database) to 
rate particular service event (s) occurring in the 
(com/service/multimedia) network under the control of the 
client. The Server reserves the money according to the 
rating result from the account and allocates the number of 

10 the events and a duration during which the events are to 

be used or the server to be recontacted. Return message is 
sent back to the client. Upon subscriber having used the 
service events, the client requests the server to withdraw 
the monetary amount from the account . 

15 In the new protocol mechanism solution according to 

the present invention a client is able to provide a 
mechanism to calculate the total cost of the service 
events (s) used during a particular service session 
according to the information provided the Charging Server. 

20 This solution addresses the possibility to return an 

estimate on the cost for the service event (s) before the 
service event (s) are executed, and final exact cost after 
the execution of the service event (s) for the served 
subscriber. This cost can be advised as a money. 

2 5 The new protocol mechanism solution according to the 

present invention will improve the existing charging 
systems by enabling account debiting based on charges 
calculated by the interrogating network. The presented 
charging mechanism can be applied for instance to on-line 

3 0 charging of events occurring in Service Network and IP 

Multimedia Network. However, note that the solution is not 
restricted to those networks but the client can exist in 
any network. 

The new protocol mechanism solution according to the 
35 present invention will also improve the existing charging 
systems by enabling service rating based on service event 
information received from Service Network or IP multimedia 
network or some other network. The new protocol mechanism 
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solution according to the present invention will further 
improve the existing charging systems by enabling 
providing the cost estimation before service execution and 
final cost after service execution. 
5 The present invention is further described in the 

Internet Engineering Task Force (IETF) contribution: 
"Diameter Credit Control Application" . 

In another embodiment of the invention shown in FIG 
6 system includes an intelligent network IN with a 

10 signalling network, which performs message switching 
between network elements. In this embodiment of the 
invention, a specific type of signalling protocol, Camel 
Application Part (CAP) 21 for GSM/UMTS, is used as a 
carrier for the exchange of information messages and 

15 carries many types of information elements, which are 

useful for intelligent network services. However, CAMEL is 
only an example and the signalling protocol can be based 
on another protocol such as the Internet Protocol (IP) , 
signalling system 7 (SS7) , IN Application Part (INAP) for 

2 0 fixed networks - where CAP and INAP are transported on 

SS7/C7/SIGTRAN. Additionally, the intelligent network 
includes a service switching function (SSF) 22, which is 
usually located in the (G)MSC 23 in GSM systems. The SSF 
22 detects events indicating a call requiring IN and after 
25 this triggering, it suspends call processing and starts a 
series of transactions with a service control function SCF 
24. In this embodiment the SCF 24 is located at an SCP 
(Service Control Point) 25 handling an IN services, i.e 
clients 1, 14, such as Premium Rate calls, Mobile Virtual 

3 0 Private Network (VPN) , Prepaid charging and Personal 

Number. In order to provide prepaid charging of IN 
services, the charging server is adapted to handle the on- 
line rating and charging. In this embodiment the charging 
server is a CCN (Charging Control Node) 22. Hence, an IN 
35 service of the SCP 25 sends charging data to the CCN 26 

via another embodiment 27 of the on-line charging protocol 
according to the invention. 
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A charging request message from the SCP 25 to the 
CCN 26 includes an IN service parameter and an IN service 
information parameter. The IN service parameter identifies 
the IN service and the IN service information is used to 
5 differentiate between different usage of the same IN 
service, for example on-net and off -net calls in VPN. 

Answer messages from the CCN 26 to the SCP 25 
includes parameters as well, for handling the call control 
and end user communication connection, i.e the IN part of 

10 the prepaid service, in connection with account status 

received from the CCN 26. An account status parameter has 
different values to convey the status of the subscriber 
account to the SCP 25. In this embodiment the different 
values are active, supervised or barred. Active implies 

15 that the account can be charged; supervised implies that 
the account can be charged but there are warnings, for 
instance that the account will soon be barred, and barred 
implies that the account can not be charged. 

Additionally, it is necessary for the IN service to 

20 be able to handle the call control and end user 

communication in connection with the amount available on 
the account, that it would receive from the CCN 26. An 
account value parameter has different values to convey the 
available amount of the subscriber account to the SCP 25. 

25 In this embodiment the different values are large, 

medium or small. Theses values implies that the account 
has funds that will cover more than the normally assigned 
duration or volume, cover only the normally assigned 
duration or volume, or not cover the normally assigned 

3 0 duration or volume, respectively. 

Figure 7 illustrates a message sequence for account 
debiting in the system for charging in the communication 
network in figure 6. When a VPN call is initiated from a 
subscriber the MSC 23 notices that IN should be invoked 

3 5 for the call and the SSF 22 sends an Initial DP to invoke 
the SCP 25 in step 28. The SCP 25 invokes the requested IN 
service, i.e VPN in this example, and sends a rating 
request to the CCN 26 in step 29. The CCN 26 checks the 
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account and notice that the subscriber needs to be warned 
about a low account, and send the result back to the SCP 
25 in step 30. In step 31, the SCP 25 checks the result 
and. notices that the subscriber should be warned, wherein 
5 the SCP 25 instructs the SSF 22 to connect to an SRF 
(service rating function) 22'. Further, the SCP 25 
instructs the SRF 22' to play an announcement to the 
subscriber in step 32. When the call is disconnected the 
SCP 25 requests a report from the SSF 22 in step 33. In 

10 the next step 34, the SCP 25 instructs the SSF 22 to 

connect the VPN call. The call is connected and proceeds 
in step 35. When the call is disconnected the SSF 22 
informs the SCP 2 5 of the disconnection and replays to the 
requested report in step 36. The SCP 25 invokes the IN 

15 service and sends a charging request to the CCN 26 via the 
on-line charging protocol 27 in step 37. The CCN rates the 
call and charges the account, after which it sends the 
result back to the SCP 25 in step 38. The disconnection is 
continued when the SCP 25 instructs the SSF 22 to do so in 

2 0 step 39. 
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1. A system for charging in a communications 
network, comprising a client (1) associated with the 

5 network for providing services to subscribers associated 
with the network, characterized in that 

the system comprises a charging server (2) adapted 
to handle subscriber account information, 

said client (1) is adapted to send a first charging 
10 request message for a service, to the charging server (2) 
before the service is provided, using an on-line charging 
protocol (3) , 

said charging server (2) is adapted to perform pre- 
reservation of an amount of resources from the 
15 subscriber's account, said amount depending on a requested 
amount included in said message; and to return an answer 
message including information indicating whether an amount 
of resources is pre-reserved from said subscriber account 
for enabling usage of said service to the client (1) using 

2 0 said on-line charging protocol (3) . 

2. A charging system according to claim 1, 
characterized in that the client (1,14) is adapted to send 
a second charging request message (6,10) to the charging 

25 server (2,17) using said on-line charging protocol (3,18), 
said request message (6,10) including the amount of 
resources used by the subscriber, 

the charging server (2,17) is adapted to deduct the 
amount of resources used by the subscriber from the 

3 0 subscriber's account, and to return an answer message 

(7,11) to the client (1,14) using said on-line charging 
protocol (3,18), wherein the answer message (7,11) 
includes the amount of resources used for the usage of 
said service . 

35 

3. A charging system according to claim 1 or 2 , 
characterized in that said first charging request message 



WO 03/032657 



PCT/SE02/01840 



21 

includes subscriber identification and a value of the 
amount of resources requested. 

4 . A charging system according to any of the 
5 preceding claims, characterized in that said first 

charging request message includes the allowed duration for 
the consuming of the reserved resources. 

5 . A charging system according to any of the 

0 preceding claims, characterized in that the first charging 
request message expresses the requested amount of 
resources as a monetary value, and that the charging 
answer message expresses the reserved monetary amount as a 
monetary value . 

6 . A charging system according to any of the claims 
1-4, characterized in that 

the first charging request message expresses the 
requested value as a number of service events, 
0 the charging server (2) is adapted to rate the 

service events, and 

the charging answer message expresses the reserved 
monetary amount as a number of reserved service events. 

5 7. A charging system according to any of the claims 

1-4, characterized in that 

the first charging request message expresses the 
requested value as a length of service time, 

the charging server (2) is adapted to rate the 
0 service events, and 

the charging answer message expresses the reserved 
monetary amount as a length of reserved service time. 

8 . A charging system according to any of the claims 
5 1-4, characterized in that 

the first charging request message expresses the 
requested value as a volume for data transfer, 
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the charging server (2) is adapted to rate the 
service events, and 

the charging answer message expresses the reserved 
monetary amount as a reserved volume for data transfer. 

5 

9 . A charging system according to any of the 
preceding claims, characterized in that the on-line 
charging protocol (3) is based on the Diameter protocol. 

10 10. A charging system according to any of the claims 

1-8, characterized in that the on-line charging protocol 
(3) is based on the Parlay protocol. 



11. A charging system according to any of the claims 
15 1-8, characterized in that the on-line charging protocol 
(3) is based on the SS7 protocol. 



12 . A charging system according to any of the claims 
1-8, characterized in that the on-line charging protocol 
20 (3) is based on the INAP CS1 protocol. 



13 . A charging system according to any of the 
preceding claims, characterized in that the client is an 
IN service. 

25 

14. A charging system according to claim 13, wherein 
the IN service is a Premium Rate call, Mobile Virtual 
Private Network (VPN) call, Prepaid charging or Personal 
Number. 

30 

15. A system for charging in a communications 
network, comprising a client (1) associated with the 
network for providing services to subscribers associated 
with the network, characterized in that 

3 5 the system comprises a charging server (2) adapted 

to handle subscriber account information, 

said client (1) is adapted to send a first charging 
request message for a service, to the charging server (2) 
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before the service is provided, using an on-line charging 
protocol (3) , 

said charging server (2) is adapted to rate the 
service and return an answer message (13) to the client 
5 (1) using an on-line charging protocol (3) , (18) , said 
answer message (13) including the price indication (s) of 
the requested service. 

16. A method for charging in a communications 
10 network comprising a client (1,14) associated with the 

network for providing services to subscribers associated 
with the network and a charging server (2,17) adapted to 
handle subscriber account information having the 
subscriber account information, characterized by the steps 
15 of : 

said client (1,14) sending a first charging request 
message for a service, to the charging server (2,17) 
before the service is provided, using an on-line charging 
protocol (3,18), 

2 0 said charging server (2,17) performing pre- 

reservation of an amount of resources from the 
subscriber's account, wherein said amount depends on a 
requested amount included in said message; and returning 
an answer message including information indicating whether 

25 an amount of resources is pre-reserved from said 

subscriber account for enabling usage of said service to 
the client (1,14) using said on-line charging protocol 
(3,18) . 

30 17. A method according to claim 16, characterized by 

the further steps of: 

said client (1,14) sending a second charging request 
message (6,10) to the charging server (2,17) using said 
on-line charging protocol (3,18), wherein said request 
35 message (6,10) includes the amount of resources used by 
the subscriber, 

the charging server (2,17) deducting the amount of 
resources used by the subscriber from the subscriber's 
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account, and returning an answer message (7,11) to the 
client (1,14) using said on-line charging protocol (3,18), 
wherein the answer message (7,11) includes the accumulated 
amount of resources used for the usage of said service . 

5 

18. A method according to claim 16 or 17, 
characterized in that said first charging request message 
includes the allowed duration for the consuming of the 
reserved resources. 

10 

19. A method according to any of the claims 16-18, 
characterized in that the charging request message (4,8) 
expresses the requested value as a monetary value, and 
that the charging answer message (5,9) expresses the 

15 reserved monetary amount as a monetary value. 

20. A method according to any of the claims 16-18, 
characterized in that the charging request message (4,8) 
expresses the requested value as a number of service 

20 events, and that the charging answer message (5,9) 

expresses the reserved monetary amount as a number of 
reserved service events. 

21. A method according to any of the claims 16-18, 
25 characterized in that the charging request message (4,8) 

expresses the requested value as a length of service time, 
and that the charging answer message (5,9) expresses the 
reserved monetary amount as a length of reserved service 
time . 

30 

22. A method according to any of the claims 16-18, 
characterized in that the charging request message (4,8) 
expresses the requested value as a volume for data 
transfer, and that the charging answer message (5,9) 

35 expresses the reserved monetary amount as a reserved 
volume for data transfer. 
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23. A method for charging in a communications 
network comprising a client (1,14) associated with the 
network for providing services to subscribers associated 
with the network and a charging server (2,17) adapted to 

5 handle subscriber account information having the 

subscriber account information, characterized by the 
steps of : 

said client (1) sending a first charging request 
message for a service, to the charging server (2) before 
0 the service is provided, using an on-line charging 
protocol (3) , 

said charging server (2) rating the service and 
returning an answer message (13) to the client (1) using 
an on-line charging protocol (3,18), wherein said answer 
5 message (13) includes the price indication of the 
requested service. 

24. A method according to claim 23, characterized in 
that the charging request message (12) expresses a request 

0 for the price of a service event (s) , and that the charging 
answer message (13) expresses only price indications of 
the requested service event (s) . 

25. A method according to any of the claims 16 or 
5 23, characterized by the further step of: the charging 

server (2,17) deducting the account based on the reserved 
amount of resources. 

26. A method according to any of the claims 18-25, 
0 characterized in that the client is an IN service. 

27. A method according to claim 26, wherein the In 
service is a Premium Rate call, Mobile Virtual Private 
Network (VPN) call, Prepaid charging or Personal Number. 

5 

28. A charging server for charging service usage in 
a communications network, characterized in that 

the charging server (2) is adapted to: 
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handle subscriber account information, 
receive a first charging request message for a 
service from a client (1) , before the service is 
provided, using an on-line charging protocol (3), 

5 perform pre-reservation of an amount of resources 

from the subscriber's account, said amount depending on a 
requested amount included in said message about said 
service, and to return an answer message including 
information indicating whether an amount of resources are 

0 pre -reserved from said subscriber account for enabling 

usage of said service to the client (1) using said on-line 
charging protocol (3) . 

29. A charging server according to claim 28, 

5 characterized in that the charging server (2,17) is 
adapted to: 

receive a second charging request message (6,10) 
from the client (1,14) using said on-line charging 
protocol (3,18), said request message (6), (10) including 

0 the amount of resources used by the subscriber, 
deduct the amount of resources used by the 
subscriber from the subscriber's account, and return an 
answer message (7,11) to the client (1,14) using said on- 
line charging protocol (3,18), wherein the answer message 

5 (7,11) includes the accumulated amount of resources used 
for the usage of said service. 

30. A charging server according to claim 28 or 29, 
characterized in that said first charging request message 

0 includes subscriber identification and a value of the 
amount of resources requested. 

31. A charging server according to any of the claims 
28-30, characterized in that said first charging request 

5 message includes the allowed duration for the consuming of 
the reserved resources. 
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32. A charging server according to any of the claims 
28-31, characterized in that the first charging request 
message expresses the requested amount of resources as a 
monetary value, and that the charging answer message 

5 expresses the reserved monetary amount as a monetary 
value . 

33. A charging server according to any of the claims 
28-31, characterized in that 

10 the first charging request message expresses the 

requested value as a number of service events, 

the charging server (2) is adapted to rate the 
service events, and 

the charging answer message expresses the reserved 
15 monetary amount as a number of reserved service events. 

34 . A charging server according to any of the claims 
28-31, characterized in that 

the first charging request message expresses the 
2 0 requested value as a length of service time, 

the charging server (2) is adapted to rate the 
service events, and 

the charging answer message expresses the reserved 
monetary amount as a length of reserved service time. 

25 

35. A charging server according to any of the claims 
28-31, characterized in that 

the first charging request message expresses the 
requested value as a volume for data transfer, 
30 the charging server (2) is adapted to rate the 

service events, and 

the charging answer message expresses the reserved 
monetary amount as a reserved volume for data transfer. 

35 36. A charging system according to any of the claims 

28-35, characterized in that the client (1) is a 
service/network element (14) and that the charging server 
(2) is a credit control server (17) , wherein and the 
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credit control server (17) performs the credit check and 
the pre-reservation. 

37. A charging server according to claims 36, 
5 characterized in that the credit control server (17) 

performs the rating of the service. 

38. A charging server according to any of the claims 
28-37, characterized in that the on-line charging protocol 

10 (3) is based on the Diameter protocol, the Parlay 

protocol, the ss7 protocol, or the INAP CS1 protocol. 

39. A charging server for charging service usage in 
a communications network, characterized in that 

15 the charging server (2) is adapted to: 

handle subscriber account information, 
receive a first charging request message for a 
service from a client (1) , before the service is provided, 
using an on-line charging protocol (3) , and 
2 0 rate the service and return an answer message (13) 

to the client (1) using an on-line charging protocol (3) , 
(18) , said answer message (13) including the price 
indications of the requested service event (s) . 

2 5 4 0. A charging server according to any of the claims 

2 8-39, characterized in that the client is an IN service. 

41. A charging system according to claim 40, wherein 
the In service is a Premium Rate call, Mobile Virtual 

3 0 Private Network (VPN) call, Prepaid charging or Personal 

Number . 
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